There are numerous deployments and varieties of electronic locks that are utilized to provide secure access to buildings or other objects, for example, safes, automobiles, etc. Authentication is generally provided through a wide variety of means including keypads, cards, bio readers and other authentication input devices. In conjunction with the deployments, a need has developed for various types of functions or information relating to the secured door with which one needs to communicate. Improvements to the security, installation, maintenance, adding or removing users, and support of access control devices are also areas of growing need. For example, it is frequently desirable in a security system application project to enable the integration of components or devices from different manufacturers. This presents a number of challenges particularly when components may not communicate in the same manner or support the same signals, for example. To address this issue in the case of card reader based authentication devices, a de facto wiring standard was developed for card readers—the Wiegand interface. The interface is utilized to connect card readers to a controller and/or the rest of the access control system. Wiegand is also used as an interface in time and attendance systems. The Wiegand interface utilizes three wires. One wire is a common ground and the other two wires are used for data transmission (Gnd, DATA0, DATA1). Zeros are impulses on the DATA0 line and ones are impulses on the DATA1 line. The communication protocol used on a Wiegand interface is referred to as the Wiegand protocol. In the Wiegand protocol, data bits are prefixed and postfixed with parity, and length/chunks of data bits can vary from 24 to 40 bits. The Wiegand protocol provides a level of compatibility and interoperability for readers and control panels that can be used by consultants, specifiers, and end users when setting product design or system installation criteria.
Numerous companies have developed their own custom variations of the Wiegand format. Typically, the alternatives are developed by those that require more codes. One such variation is the 39 bit Wiegand format, which contains 17 bits for the facility code and 20 bits for the ID number field. Consequently, this allows for a total of 131,072 facility codes, and the 20 ID number bits allow for a total of 1,048,576 individual IDs within each facility code.
Irrespective of the code variation however, the Wiegand based data communication between a controller and a card reader or other peripheral device has always been unidirectional. The peripheral device sends data to the controller but there is no data communication in the other direction. This presents several drawbacks and limits what can be done. For example, because the controller has no bi-directional data communication with the reader, reader device identification or reader device authentication is not possible. Newer access systems are thus unable to provide extended features if they want to remain compatible with the de facto communication standard.
Another issue that plagues the traditional access control systems that utilize a card reader and controller relates to the method for programming the controller, such as maintaining credentials or authorized identities. Such maintenance might include user card management, i.e., adding or deleting user cards to/from the system, or perhaps performing user identification code changes.
Heretofore, card readers require specialty cards that are encoded as programming cards (i.e., cards that will allow the end user to make maintenance changes such as user card management). For example, a particular programming card would be provided to the end user from the manufacturer to be used for placing the controller into ‘add mode’ and another card may be provided for placing the controller into ‘delete mode.’ When the controller is in add mode, it essentially learns a new credential that is presented to it, for example, a new badge for user Joe that will provide access to doors 1 and 4 only on the 10th floor of the building. In delete mode, it will delete the credential that is presented (i.e., remove the authorization access associated with the presented card).
These specialty program cards have to be provided by the manufacturer, and if a specialty program card is lost, a replacement card would have to be ordered from the manufacturer. This requirement and method is at best cumbersome and inefficient, it places the end user company at the mercy of the manufacturer and worse yet could pose a major security risk. For example, when there is an immediate need perhaps to delete a particular card user's credential from the system over a weekend or holiday period, the company would be vulnerable in the event of a lost program ‘delete card’ until the company can reach the manufacturer and ultimately have a new program delete card delivered on site.
Further, in the prior art, retrieval of a forgotten user code or password could be achieved by the user reciting the answer to a previously provided secret question. However, if the answer is unknown because the previous user has left the company, replacement of the old user code/password could not be accomplished without replacing an EEPROM hard-soldered to the circuit board. Once again, the company's security could be vulnerable during the down time to replace the EEPROM.
Yet another issue that affects the industry relates to the issue of communication between a personal computer (PC) and the controller of the access control system. Data in the form of configuration information, software updates, and report information is generally communicated between the PC and the controller via a Universal Serial Bus (USB) port. Such transmitted data needs to be encrypted for security reasons. However, a number of problems exist with traditional and currently available solutions.
One solution has been the use of a Private static cipher key that is hard coded into both the PC program and the controller. If the private key is ever discovered all controller units become compromised.
Another solution is a private static cipher key that pairs a particular controller to a particular PC. Having multiple private keys increases security as the compromise of one controller unit does not compromise all the other addresses and resolves the earlier problem. However, the problem in this case lies in the fact that the controller is now stuck or locked into a single PC. This means that only the particular PC can be used to communicate with that controller. This could be problematic to the customer should that PC get damaged or someone else needs to take over the task of managing the controller with their own PC.
Yet another solution is public key asymmetric cryptology. This option is widely used across the board and on the internet. It is proven and is secure but it requires more ‘horsepower’ than is vailable with the microcontroller typically found in most access control system controllers. As such this method is not technologically feasible to implement on the controller.
What is needed is a system and method that allows bi-directional data communication between a controller and peripheral devices, which is versatile enough to accommodate enhanced surveillance or security features, without the drawbacks described above. Further, a robust system that would enable for example, any standard Wiegand 2601 card to become the “Master Add” or “Master Delete” card for the controller, while providing ease of installation and avoiding the short comings of current systems, would be advantageous. Further still, providing for dynamically generated cryptographic keys in a PC and the controller of an access control system during each communication occurrence, without the use of standard public key algorithms, would also be advantageous. The present invention fills these as well as other needs.